1. Field of the Invention
The present invention relates to computer software, and deals more particularly with methods, systems, and computer program products for migrating configuration data used by an existing executable computer code to a replacement executable computer code. Configuration data is gathered by a pre-existing, first executable computer code, formatted in a form suitable for use by a second executable computer code, and output so that it can be accessed by the second computer code upon invocation. This reduces the effort required to gather configuration data necessary to allow a second executable computer code to take over the functions of a first executable computer code.
2. Description of the Related Art
In today's rapid advance of technology, a computer system composed of software, firmware, and hardware is inevitably in a continuous state of change. In particular, the instruction sequences used to perform a useful and specific task within the context of the computer system can be implemented as software (generally, a stored sequence of instructions or codes which are copied into volatile computer memory for execution), firmware (as, for example, in read-only memory chips, where the instructions or codes are burned into the device executing them), hardware (as, for example, in programmable logic arrays, analog devices, ladder logic relays, etc.), or some combination of these different methodologies. These instruction sequences, also known as executable computer code or executable code, are distributed as products, or “executable products”, which are selectively initiated and executed by the user according to the user's requirements. These executable products are executed within a computer system environment which undergoes continuous change. Such change is caused by many factors. Portions of the hardware upon which the executable product operates may be upgraded to replace old capabilities with new ones, and this necessitates concomitant changes in the executable product. Other executable products with which the subject executable product interacts may change as the result of enhancements or error corrections, and new executable products may be added to the computer system environment which will affect the performance of the subject executable product. Even if nothing on the computer system changes, there may be changes in external computer systems with which the computer system interacts, and these external computer system changes may necessitate changes in the subject executable product for compatibility or standardization reasons.
It is standard practice in the computer programming art to define sets of parameters defining commonly required values for use by multiple executable products within a particular computer system and which can be easily accessed by such products. These parameters are usually made available in the form of global tables or disk files called “configuration files” or “profiles”. For example, these sets of parameters may contain values which identify the peripheral hardware devices currently configured in the hardware, the characteristics of the peripheral hardware, the status of the peripheral hardware, address assignments for communications ports, etc. These data may be characterized as identifying the general operating environment within which the executable products are expected to operate. Other sets of parameters characterize the configuration of the particular computer system upon which the executable product resides; such data are generally static, i.e. they do not necessarily change as the dynamic computing environment changes. For example, under a virtual operating system environment within which several operating systems may coexist, such as under the International Business Machines (“IBM®”) MVS™ operating system, such data might be an identification of the operating system under which the executable product executes (e.g. UNIX, or OS/360), the type of disk file system that the executable product is expected to access, the locations of various system-related files, etc. (“IBM” is a registered trademark, and “MVS” is a trademark, of the International Business Machines Corporation, hereinafter “IBM”.) Still other sets of parameters are unique to the executable product and contain information which allows the executable product to perform certain functions in a certain way. Each executable product, in order to make it capable of executing on general systems, will access these various sets of parameters and use those parameters which are pertinent to its operation. This allows the executable product to adjust its operation to accommodate various environmental conditions and thus be more universal in its usefulness.
It is often necessary on computer systems either to upgrade an existing executable product with a newer version of the same executable product or to replace an existing executable product with a different executable product. In either case, it often happens that there exists extensive configuration data used by the existing executable products. In order to install a replacement executable product, such existing configuration data must frequently be altered and reformatted for use by the replacement product, depending upon its requirements. This process is sometimes referred to as data migration. This process of data migration is often tedious, error-prone, and inconvenient.
In the prior art, there are generally three common methods for migrating configuration data. These three methods are depicted in FIGS. 1A, 1B, and 1C. According to the first method as depicted in FIG. 1A, the replacement executable product 115 “imports” the configuration data 111 of the existing executable product 112 by directly reading the configuration files 111 of the existing executable product 112 and then saving the configuration data 114 in the format that the replacement executable product accepts. Later invocations of the replacement executable product 115 would read its configuration data 114 in its standard operational format. This is most commonly done, especially when an executable product is updated with a newer version and the newer version uses a new format for configuration data. This method requires additional code to be implemented in the replacement executable product 115 to find, recognize, read, interpret, and error-check the configuration files 111 of the existing executable product 112. Such additional code is not normally required after the replacement operation and remains to unproductively consume computer system resources such as storage space. It also places a burden on the programmers responsible for maintaining the replacement executable code, in that the data migration code must be maintained and documented as long as the replacement executable product is viable.
According to the second method of migrating data as depicted in FIG. 1B, a separate executable product called a migration utility 123 is provided to read the specific configuration files 121 of the existing executable product 122, as well as the general configuration files required and/or maintained by other executable products (not shown in FIG. 1B) within the computer system environment; translate the data contained therein; and output the data as configuration files 124 in a format acceptable to the replacement executable product 125. This might be done in the prior art when the replacement executable product 125 is not aware of or able to read configuration files 121 from the existing executable product 122. This method has the disadvantage of requiring the design, coding, testing, and maintenance of an additional executable product that understands and translates between two different configuration file formats.
The third, and least desirable, method of migrating data is a manual process, depicted in FIG. 1C, in which the system administrator 133 or user manually creates configuration files 134 for the replacement executable product 135, e.g. by following instructions provided in the documentation for the replacement executable product 132, by inspection of the existing configuration data files 131, or other manual means. This method is very tedious and time consuming, prone to human error, and dependent upon the level of training and skill of the individual making the manual changes.
Both the first and second method have additional disadvantages and limitations. The biggest disadvantage is that the executable product 112, 122 being replaced may obtain its configuration information 111, 121 from many sources; however, not all of these sources are necessarily accessible to the replacement executable product. For example, consider a routing daemon which gets its configuration information from input files, start up “command line” parameters, and information learned in communication with its routing stack. If the new routing daemon obtains its configuration information from configuration files only, then neither the new routing daemon nor a stand-alone migration utility can access the command line parameters that would have been used to initiate the existing routing daemon. Furthermore, the replacement program does not have facilities for learning information from the routing stack which is internal to the old routing daemon, and instead expects to have that information defined to it. In such a case, the solution to this problem would be the third method for migrating data given above and to include extensive documentation with the replacement program directing the system administrator or user to manually provide the information.
Accordingly, improved techniques for migrating configuration data are needed.